[Previous] [Next] [Index] [Thread]

Re: Comments on the new SHTTP draft of July, 1995

> I've tried to delete points where we seem to be in agreement....

So, once we have an empty mail message, we're done. :-)

> >> >I'm assuming the standard padding mechanism defined in section 6.2 of
 [ ... ]
> >> Actually, this doesn't work properly. Consider the case of DES
> >> where the keylength is exactly equal to the blocksize.
> >
> >Then you pad by adding eight bytes of value 08.  It's unfortunate that
  [ ... ]
> True, this is the canonical padding scheme for CBC, but not necessarily
> for ECB mode. If you look at RFC-1423, S 5, you'll see
> that the mode of employment for DES-ECB as a DEK encryption
> algorithm where the DEK is for DES-CBC (i.e. 64 bits) is
> to simply encrypt the DEK as one cipher-block in ECB
> mode.

Yes, you can get away with this when you know in advance that the
plaintext will not require any padding.  However, since we're not
algorithm-specific, we don't know with certainty that the key size
(and block size, for that matter) will work out that way.  I don't
see anything specific to CBC mode in padding; it's inherintly necessary
for any block cipher.

Actually, it gets even more potentially confusing when you consider
that keys for ciphers like RC2 and RC4 don't even need to be even multiples
of entire bytes, let alone even multiples of entire blocks.  There's currently
no way to specify an RC2 key of, say, 44 bits, although you can specify a 6
byte secret suitable only for the algorithm rc2-ecb[44], which is close enough.

I think this is OK, since it's not possible to put portions of a byte
through most other algorithms (other ciphers, MD5, etc.)  This conversion
has to go the other way if we let algorithm identifiers from the encrypted
content dictate key size.

> In any case, The only reason to do this kind of padding (as
> opposed to say simple padding with zeros) is to unambiguously
> distinguish the end of the data, when the end of the data isn't
> otherwise unambiguously determined. I'd rather arrange that
> the keylength is unambiguously determined and then pad with
> zeros or random data in the cases where it's necessary to
> fill out a cipher-block.

Well, there are a couple approaches:
- Use standard padding
- Add an extra field to the Prearranged-Key-Info: field to indicate the
  length of the DEK (or maybe the number of padding bytes in it.)

Neither one is backward-compatible, alas.  I don't see an overwhelming reason
to prefer one over the other, though at least padding doesn't change the
syntax of the header field.

> The only time you'd use DEK would be if you were encrypting the message,
> in which case you would know the algorithm you were using and therefore
> the keylength. Except, possibly, for the case of RC4, which I agree,
> could be a problem. I'll look into it.

It's a potential problem with RC4; I also don't particularly like the idea of
requiring looking inside this level of detail of structure of the encrypted
body to determine the secret size for purposes of computing MACs, since
authentication and encryption are supposed to be orthogonal enhancements.
This seems to tie them together a bit more intimitely than is needed.

> >Yes.  Being good for perhaps only one transaction, and being good for lots
> >of transactions over the duration of a connection, are different things.
> >I'd expect we'll want a different label for "session" keys with longer
> >lifetimes than a single use.
> 
> Of course, since we don't have retained connections, this is a bit
> of a moot point, but a fair one nevertheless. 

Yes, but I'd expect we will, and exchange of a single inband key for the
duration of a session (a la SSL) is going to be a desirable thing (provided
we don't allow RC4 to be used as a symmetric-head-key.)

> >I'm also still vague on the purpose of "this".
> I intended 'this' to be used for Key-Assigns which were
> supposed to refer to keys used in the message in which they appear.
> So, for instance, you could use the Kerberos method to assign
> a key (in the S-HTTP headers) which you then used to encrypt
> the message that followed. 

Ah; had forgotten about the kerberos case (has anybody actually implemented
kerberos in SHTTP?)  Fair enough.

- Marc
References: